refactor(queue): port queue show's dequeue diagnosis onto mergify-events - #1759
Conversation
|
This pull request is part of a Mergify stack:
|
Merge Protections🟢 All 6 merge protections satisfied — ready to merge. Show 6 satisfied protections🟢 🤖 Continuous Integration
🟢 👀 Review Requirements
🟢 Enforce conventional commitMake sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
🟢 🔎 Reviews
🟢 📕 PR description
🟢 🚦 Auto-queueWhen all merge protections are satisfied, this pull request will be queued automatically. |
2538e85 to
c4884b2
Compare
6220917 to
f6b6132
Compare
Revision history
|
c4884b2 to
6bacff8
Compare
`queue show`'s activity-log fallback was the CLI's first `/logs` consumer, and `last_leave.rs` (744 lines) carried the whole endpoint contract itself: the explicit 90-day window, the newest-first ordering assumption, the single-page fetch. That contract now has one home — the `mergify-events` crate — so this deletes the module and rebuilds the diagnosis as its `queue_leave` explain layer: - the fetch goes through `mergify_events::fetch` with `Window::retained` and `limit: 1`; the wire shape is unchanged (same filters, same `per_page=1`), but the window/pagination/ ordering traps are the shared client's tests' problem now - the decode types, the renderer (headline, facts block, the API's own reason prose, failing checks with job URLs, next step) and the no-activity notice move verbatim to `mergify_events::queue_leave` — the two queue-specific traps they guard (leave events vs `checks_end` abort codes, `metadata.merged` telling a merge from a dequeue) are documented there - `queue show` keeps its exact behavior: same human wording (the `PR #N is not in the merge queue` line the live smoke tests pin), same `--json` contract (`dequeued` tri-state, `queue_leave` verbatim, promoted `queue_leave_head_sha`), same 403 degradation — every test that pinned that behavior moved or stayed, none was weakened Net for mergify-queue: -744 lines, and no /logs knowledge left in the crate. Part of MRGFY-8363. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Change-Id: Ie13a945a4eddfdfcf5d998958c04950a7c0a0594
6bacff8 to
b2faf78
Compare
|
Rebased onto The base of this stack, #1758, merged this morning as
Verified standalone at this commit (each commit is its own PR with its own CI): |
Merge Queue Status
This pull request spent 29 seconds in the queue, including 4 seconds running CI. Required conditions to merge
|
…1760) The activity log carries ~45 event types — the action.queue.* family, the workflow actions, ci_insights.*, command.*, queue pauses, scheduled freezes — and almost none of it was reachable from the CLI, so agents hand-rolled curl against a contract they did not know. Add `events` as a new top-level noun over the shared client: mergify events # whole repo, last 24h mergify events --pr 1740 --since 7d mergify events --type action.queue.leave --type command.queue mergify events --pr 1740 --json # raw events, newest first mergify events --limit 20 # newest 20, and the header says so One command over a filter covers every type; there is deliberately no command per event type. Two details carry the lesson #1747 taught: - **The header always states the window** (`PR #1740 · 6 events · 2026-07-29 21:00 → 2026-07-30 21:00 UTC`), so an empty result reads as "nothing in the last 24h" and never as "nothing ever" — that ambiguity is the bug this removes. The empty case names the range and the retention: `No events for PR #1740 between <from> and <to> UTC.` / `Retention is 90 days; try --since 90d.` (the hint is omitted when the query already covered the full retention). - **`--since` cannot express a window the API would reject**: the duration parser enforces the 93-day cap as a usage error carrying the fix, and the 24h default is applied by the CLI and stated, not inherited silently from the API. The human timeline reads oldest-first with a dim date row wherever the calendar date changes, and a best-effort summary per line (queue name, draft PR number, abort/dequeue codes, merged, command author) that degrades to nothing on types this CLI has never seen. `--json` emits one document echoing the query (`repository`, `pull_request`, `received_from`, `received_to`) plus `size` and the raw events newest-first, unknown fields intact. Verified against the live API on Mergifyio/mergify-cli: the full queue lifecycle of #1747 (enter → checks_start → checks_end → leave merged), a 30-day repo-wide query paginating to completion (806 events over 9 pages, newest-first), the --type filter, and the empty case naming its window. Docs: README command list, a new `mergify-events` agent skill, the `mergify-merge-queue` skill now routes "whole lifecycle" questions to `mergify events` instead of curl, and AGENTS.md maps the new group. Fixes MRGFY-8363. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Depends-On: #1759
queue show's activity-log fallback was the CLI's first/logsconsumer, and
last_leave.rs(744 lines) carried the whole endpointcontract itself: the explicit 90-day window, the newest-first
ordering assumption, the single-page fetch. That contract now has one
home — the
mergify-eventscrate — so this deletes the module andrebuilds the diagnosis as its
queue_leaveexplain layer:mergify_events::fetchwithWindow::retainedandlimit: 1; the wire shape is unchanged(same filters, same
per_page=1), but the window/pagination/ordering traps are the shared client's tests' problem now
reason prose, failing checks with job URLs, next step) and the
no-activity notice move verbatim to
mergify_events::queue_leave— the two queue-specific traps theyguard (leave events vs
checks_endabort codes,metadata.mergedtelling a merge from a dequeue) are documented there
queue showkeeps its exact behavior: same human wording (thePR #N is not in the merge queueline the live smoke tests pin),same
--jsoncontract (dequeuedtri-state,queue_leaveverbatim, promoted
queue_leave_head_sha), same 403 degradation —every test that pinned that behavior moved or stayed, none was
weakened
Net for mergify-queue: -744 lines, and no /logs knowledge left in the
crate.
Part of MRGFY-8363.
Co-Authored-By: Claude Fable 5 noreply@anthropic.com